-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
matter/fast pair: Add support for merging hex files without partition manager #18792
base: main
Are you sure you want to change the base?
Conversation
Adds support for merging other files onto the uicr_merged.hex file Signed-off-by: Jamie McCrae <[email protected]>
Adds support for generating fast pair data for nRF54H20 which does not use partition manager Signed-off-by: Kamil Piszczek <[email protected]> Signed-off-by: Jamie McCrae <[email protected]>
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 2b3619b60e22623d9752b1445afd15b2b06472cf more detailssdk-nrf:
matter:
Github labels
List of changed files detected by CI (10)
Outputs:ToolchainVersion: b81a7cd864 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publishing GitHub Action. |
Memory footprint analysis revealed the following potential issuessample.matter.template.release[nrf7002dk/nrf5340/cpuapp]: High ROM usage: 811902[B] - link (cc: @kkasperczyk-no @ArekBalysNordic @markaj-nordic) Note: This message is automatically posted and updated by the CI (latest/sdk-nrf/PR-18792/2) |
Added nRF54H20 DK support to the Fast Pair Input Device sample. Ref: NCSDK-29602 Signed-off-by: Kamil Piszczek <[email protected]>
Updates matter to include support for generating factory data when partition manager is not used Signed-off-by: Jamie McCrae <[email protected]>
Calls the updated factory data function irrespective of partition manager enablement Signed-off-by: Jamie McCrae <[email protected]>
4df741a
to
2b3619b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
storage_partition: partition@1e3000 { | ||
reg = <0x1e3000 DT_SIZE_K(20)>; | ||
}; | ||
|
||
bt_fast_pair_partition: partition@1e8fb8 { | ||
label = "bt_fast_pair"; | ||
reg = <0x1e8fb8 0x48>; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if the addresses are correct. 20kB is equal to 0x5000 so I think the bt_fast_pair_partition
address should be set to 0x1e8000 (0x1e3000 + 0x5000) instead of 0x1e8fb8. Correct me if I'm wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I positioned it at the end of the 0x1000 memory chunk to mimick the PM solution in the case of automatic builds without the specific memory layout file (pm.yaml). On the other hand, we typically position the provisioning data at the beginning of the 0x1000 memory chunk in builds where we define the memory layout file (pm.yaml).
@alstrzebonski, I don't have a preference here. We can align it according to your suggestion or we can leave this part and think about the position of the fast pair provisioning data hex in the nRF54H20 memory in the follow-up task
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be aligned to my suggestion or, if we want to mimic the PM, we should add the comment explaining the gap in the memory map. I'm okay with both solutions. It can be also left as is and improved in follow-up task - maybe that's the best option considering it's @nordicjm's PR. It will be easier to leave it as is for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alstrzebonski, could you create a follow-up task?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Fast Pair part looks good to me. The configurations aspects of Fast Pair (e.g. partition position) can be improved in the follow-up PRs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couple of observations and a small proposal improvement, but nothing blocking.
# dependencies that need to be generated before hand. This will overwrite existing data if it is | ||
# present in other files | ||
function(suit_add_merge_hex_file) | ||
cmake_parse_arguments(VAR "" "" "FILES;DEPENDENCIES" ${ARGN}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better to start using arg
as prefix.
See: https://gitlab.kitware.com/cmake/cmake/-/issues/25773, and https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9788/diffs
cmake_parse_arguments(VAR "" "" "FILES;DEPENDENCIES" ${ARGN}) | |
cmake_parse_arguments(arg "" "" "FILES;DEPENDENCIES" ${ARGN}) |
if(NOT VAR_FILES) | ||
message(FATAL_ERROR "suit_add_merge_hex_file missing required argument FILES") | ||
endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be simplified and also ensure common way of printing argument errors:
if(NOT VAR_FILES) | |
message(FATAL_ERROR "suit_add_merge_hex_file missing required argument FILES") | |
endif() | |
zephyr_check_arguments_required(${CMAKE_CURRENT_FUNCTION} arg FILES) |
set_property( | ||
GLOBAL APPEND PROPERTY SUIT_POST_BUILD_COMMANDS | ||
COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/build/mergehex.py | ||
--overlap replace | ||
-o ${OUTPUT_HEX_FILE} | ||
${ARTIFACTS_TO_MERGE} | ||
${ARTIFACTS_TO_MERGE} ${merge_files} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
observation: this is really not self-explaining what the difference between ARTIFACTS_TO_MERGE
and merge_files
is.
But as this file in general is messy, then there is not change requested for this PR.
For nRF54H20 only